Goal

Let anyone add lstk <name> subcommands as independent binaries — open or closed source, built in-house or by partners — without merging them into the open-source core. lstk becomes a Git-style dispatcher that resolves and execs lstk-<name>, hands it enough runtime context to be useful, and leaves authorization to the extension. This is an OpenSpec proposal only (no implementation yet).

Approach

• Git-style dispatch: when lstk <name> isn't a built-in, lstk resolves an lstk-<name> executable and execs it, forwarding args, streams, and exit code. Built-ins always win; no in-process plugin ABI.
• Versioned LSTK_EXT_* env contract: lstk passes the resolved emulator endpoint/type/port, config dir, auth token, and resolved global-flag state (e.g. LSTK_EXT_NON_INTERACTIVE) — so extensions skip rediscovering any of it. Global flags before the command name are consumed by lstk and conveyed by env, never forwarded on the extension's command line.
• Authorization belongs to the extension: lstk just passes the auth token; an extension that needs to gate access authorizes the user itself. Because lstk is open source and rebuildable, security can't live in lstk — the lstk-side signed-grant mechanism is explicitly deferred.
• Bundled LocalStack extensions: ship LocalStack-built (closed-source) extensions like lstk-deploy by default in a directory next to the binary, resolved ahead of PATH, updated atomically with lstk. No user-facing install step.
• Side-effect-free help: bundled extensions show a one-line description read from a static file generated during release; PATH/custom extensions are name-only. lstk help never executes an extension.
• Manifest-free, deliberately narrow: no per-extension manifest (extensions self-validate via LSTK_EXT_API_VERSION). Emulator attestation and the user-facing lstk extension management commands are deferred.

See proposal.md and design.md for the full rationale, threat model, decisions, and open questions.

🤖 Generated with Claude Code